All businesses are underpinned by their processes. Process defines the competitive edge of one business over another. History is littered with examples where one company has emerged as the dominant entity as a result of its processing efficiency together with the ability to rapidly adapt its processes to market change
Today, all reasonably sized companies have some form of process automation. Most usually this is delivered using bespoke technology that enables multiple applications to communicate across a messaging infrastructure. Typically, over the years, the messaging infrastructure fragments, resulting in the processes executing across a mix of messaging environments.
Concurrently process change is introduced and most usually the documentation recording these changes fails to keep pace with the changes being implemented. Progressively visibility of the end-to-end process is lost.
Initially the loss of process visibility is at the margin, but with the passage of time the “implementation drift” becomes sufficiently pronounced to require the system to be re-documented.
The need to re-document the system most usually arises when the company is considering some form of process re-engineering, but can arise in other circumstances—for instance migrating users to a new database, only to find the old database cannot be decommissioned due to a number of “rogue” or unknown users being discovered.
Re-documenting AS-IS processes is a necessary but manually intense, error prone, time consuming task that often results in little more than an interpretation of what the process engineers think the system is delivering. This requires the task to be repeated, often multiple times, until a definitive description of what the system is actually doing is derived. It is however, a task that cannot be ignored for without a precise understanding of the AS-IS processes, migration to the TO-BE processes is extremely difficult.
The Move Towards Service Orientated Architecture
The need to re-document existing processes has become more pronounced in recent years with the accelerated move towards greater system adaptability, via the introduction of the “Service Oriented Architecture” (SOA) approach. An example of this approach might be the ClearGate™ system described in WO2009/056844.
This new approach has been specifically adopted to enable software development teams to respond rapidly to changing business demands. The present invention described herein is designed to facilitate SOA adoption.
SOA is used as a means of enabling applications to co-operate, most usually via a centralised control mechanism (described as “Orchestration”), or as required, peer-to-peer (described as a “Choreography” or a “Collaboration” dependent on circumstances). This requires the existing (and unified) processes to be decoupled from the underlying co-operating applications and for these applications to be modularised and re-presented as a set of “services”—where a “service” is a specific item of functionality, able to be accessed via a standard set of protocols. In order to implement SOA it is firstly necessary to understand the AS-IS processes.
However, precisely capturing and documenting the AS-IS processes is an error prone and time consuming task, often made more difficult in merger and acquisition situations where legacy implementations and processes are inherited, without the benefit of any knowledge transfer detailing the complexities of the inherited architecture.
Conventional Approach to Capturing the AS-IS Process
The conventional approach to capturing an AS-IS process is to firstly inspect the system documentation. This provides some insight into how the system was originally designed but provides little certainty of operation of the current environment. Invariably, over time, various degrees of adaptation and change have been introduced that have not been fully documented. Containing this implementation drift may be part-addressed by inspecting the system message logs. This assists in augmenting the overall understanding of the system, but does not provide a guarantee that all possible execution paths available to a transaction instance will be identified.
To obtain a more complete understanding of the system it thus becomes necessary to interview and re-interview staff members to understand specific sections of the overall process. This is then followed by the deployment and re-deployment of test messages and the inspection and re-inspection of often widely distributed log files to identify if a particular part of the overall system is functioning as anticipated. Once an understanding of that particular part of the system is reached this is documented using MS-Word (or equivalent) and manually generated diagrams.
This procedure repeats until an overall understanding of the production environment is reached. This usually starts well, but as the process of re-documenting the system becomes more complex, progressively more time is spent checking and re-checking system interdependencies, redrawing diagrams and rewriting the documentation. The result is one of diminishing returns, as progressively more time is spent managing the documentation process and less time is spent on system analysis.
Eventually some sort of understanding of the end-to-end process is reached and the diagrams and the MS-Word documents (now typically amounting to hundreds of pages) are given to the developers for encoding. As these diagrams and documents are only an interpretation of the system, errors, anomalies and ambiguities are common. The resulting encoding reflects this, requiring numerous errors to be unwound. As each error is unwound, this has a knock-on effect on encoding elsewhere, resulting in an enormous re-coding effort.
Currently, it is not unusual to find in excess of 3 to 6 months is expended on the capture of the AS-IS processes. This is typically followed by another 3 to 6 months expended on the TO-BE system design and deployment. The cost runs into hundreds of thousands of US dollars. It is against this background that the technology detailed in the present invention has been developed.